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This Technical Note describes known anomalies in Standard File. 

Changes since December 1991: Updated for System 6.0. Problems with the infinite loop and 
SFMultiGet2 reply record are fixed. 



Prefix Check is Case Sensitive 

When you advance to the next volume using Command- Tab (or just Tab, before 6.0), Standard 
File checks your prefix against the name of the volume now in the same device you were just 
using, to see if you switched disks (this is possible on a 5.25 drive, for example). If the name 
doesn't match, you stay at the same device. 

Unfortunately, the comparison in 6.0 and earlier is case sensitive. If you have a volume called 
"MyDisk" and prefix zero is set to ":MYDISK", advancing to the next volume doesn't get you 
anywhere the first time (but the prefix changes from ":MYDISK" to ":MyDisk"). 

The following two problems are fixed in System 6.0: 
Infinite Loop with Empty Prefixes 

In System Software versions 5.0 through 5.0.4, all Standard File dialogs can hang if both 
prefixes and 8 are empty (GS/OS uses prefix 8 to expand partial pathnames if prefix is 
empty). 

If this affects your software, use GetPref ix to check for empty prefixes before calling 
Standard File. If and 8 are both empty, set prefix to "* : " (or any other convenient 
pathname). 



SFMultiGet2 and SFPMultiGet2 in System 5.0.4 and earlier accidentally validate the 
multi-file reply record as if it were a regular new-style reply record (as for SFGetFile2, for 
example). The validation is a check that the words at offsets $08 and $0E in the record are not 
$0002 (these are nameRef Desc and pathRef Desc in a new-style reply record). 



SFMultiGet2 (and SFPMultiGet2) reply record 
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To ensure that Standard File does not erroneously reject your multi-file reply record (and return 
error $1704), you may include ten bytes of $00 following the six-byte record. 

Further Reference 

• Apple IlGS Toolbox Reference, Volumes 2 & 3 
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